Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/9311/UNDELETE.CD

Text File | 1995-04-19 | 17KB | 320 lines

          @VMS DOS 6 Undelete (Sentry)@N

          @VAmi a kézikönyvbôl kimaradt...@N

          Minden  programfelhasználót  ért  már  meglepetés, amikor az
          általa  mûködtetett  program  a felhasználás során szokatlan
          dolgokat  mûvelt.  Ilyenkor  a felhasználói dokumentáció nem
          sok  segítséget nyújtott, sôt gyakran még hasonló helyzetrôl
          sem tett említést.


          A  Microsoft  DOS  6.0-s  verziójának  igen  hasznos része a
          régóta    várt    teljes    Undelete.   Elmondhatjuk,   hogy
          valószínûleg  az  Undelete  leghasznosabb  formája  a Delete
          Sentry.    Ez    a    funkció   nemcsak   ígéri   a   teljes
          visszaállíthatóságot,  hanem  csaknem  meg  is  valósítja. A
          továbbiakban  olyan tényekre hívjuk fel a figyelmet, amelyek
          a  Sentry  helyes használatát megkönnyítik, ugyanakkor a DOS
          kézikönyv nem említi ôket.


           @VTechnikai részletek@N

          A  Delete  Sentry  lényege,  hogy  a  letörölt  file-okat  a
          rendszer   a   fôkönyvtárban   elhelyezett   rejtett  SENTRY
          alkönyvtárba  ""másolja". (Ez a másolás természetesen csak a
          file-bejegyzés  mozgatását  jelenti.)  Az átmásolt file-ok a
          SENTRY-n  belül  .MS kiterjesztést kapnak, nevük pedig a DOS
          által  generált  szám-  és betûhalmaz lesz. Visszaállításkor
          csupán  annyi  történik,  hogy  a  bejegyzés újra az eredeti
          könyvtárba  kerül,  nevét  pedig  a \SENTRY\CONTROL.FIL file
          adatai alapján az Undelete visszaállítja.

          A  Delete  Sentry  csak  akkor vesz fel egy file-t a törlési
          listára,  ha  az  a DEL (ERASE) parancs hatására szûnik meg.
          Ide  számít  a  különbözô  file-managerek törlése is. A MOVE
          parancs  vagy  vele  kompatibilis  segédprogram  azonban nem
          bôvíti  a  törölt  file-ok  listáját.  Ha tehát valamit MOVE
          után  az  új  helyérôl  törlünk  le,  csak innen tudjuk majd
          visszahozni.

          Åltalában  elmondható,  hogy  nagyon nehéz letörölni valamit
          DOS   szintû  mûveletekkel  a  tárban  aktív  Delete  Sentry
          figyelmét  elkerülve.  Ez  a  tény  nagy segítséget jelenhet
          olyan  felhasználóknak,  akiknek nincsenek mélyebb ismeretei
          a  file-rendszer  mûködésérôl.  Sajnos  a SUBST segítségével
          létrehozott  meghajtók  kivételnek  számítanak.  Ha  ugyanis
          például   a  C:  és  a  D:  védett  meghajtó,  a  C:  egység
          valamelyik  könyvtárát  D:-re  helyettesítve  (például @KSUBST@N
          @KD:   C:\TEMP@N   paranccsal),   majd   a   látszólagos   D:-re
          átlépve   s   onnan   mindent  törölve  a  Sentry  a  törölt
          file-okat  a  D:\SENTRY  hiánya miatt sehova nem jegyzi fel.
          Ilyen   esetben   a   visszahozásra  csak  a  jóval  kevésbé
          megbízható  módszerek  valamelyike marad, ezért felhasználói
          környezetben  ügyelni  kell  a SUBST használatára! Szakértôk
          számára  létezik néhány más módszer, (például a Disk Editor,
          vagy    a   könyvtár-bejegyzés   töröltté   tétele,   CHKDSK
          futtatásával  folytatva  (a  lost  clusterek  eldobásával)),
          ezek  az  eljárások  azonban  többnyire  a  DOS-t  kikerülve
          mûködnek   (BIOS-szintû   mûveleteket   a   Sentry  nem  tud
          felügyelni).


           @VUndelete és a könyvtárnevek@N

          Amint  azt  a  kézikönyv  is  említi,  az Undelete nem képes
          törölt    könyvtárnevek    visszaállítására.    A    DELTREE
          segítségével   megszüntetett   könyvtárakban   lévô   adatok
          visszahozatalához kerülô utat kell igénybe vennünk:

          1.   A   \SENTRY\CONTROL.FIL-t  megtekintve  megtudhatjuk  a
          keresett  file  teljes  elérési  útját. Ezt a könyvtárláncot
          kell   újra  létrehozni,  majd  ide  belépve  elindítani  az
          Undelete-et, innen már visszahozható a törölt file.

          2.  A  Norton  Utilities  7.0  Quick  Unerase segédprogramja
          képes  a Delete Sentry elmentett információit felhasználva a
          teljes    visszaállításra.    Ez    a   megoldás   látszólag
          kényelmesebb,     mivel     mindenféle     kutatás    nélkül
          hozzájuthatunk  a  letörölt  file-ok  listájához  (a  Norton
          Unerase  megjeleníti a könyvtárszerkezetet is), a valóságban
          azonban  nem vesz tudomást azokról a letörölt könyvtárakról,
          amelyek  könyvtárbejegyzése  már felülíródott. Ez a probléma
          akkor  jelentkezhet,  ha  a visszaállítás során megelégszünk
          az Unerase által felkínált visszaállítható könyvtárakkal.

          Példa:  a  C:\TEMP\T1  könyvtárból  minden file-t töröltünk,
          késôbb  maga  a  T1 alkönyvtár is megszûnt. Az Undelete-et a
          C:\TEMP-en  belül indítva nem kapunk információt arról, hogy
          itt  létezett  a  T1 alkönyvtár, csak a C:\TEMP-bôl letörölt
          file-ok  jelennek  meg. Ha a törlés óta nem vettünk semmit a
          C:\TEMP-be,  az  Unerase  mutatja, hogy létezett egy ?1 nevû
          alkönyvtár   is.   Ennek   elsô   karakterét   nekünk   kell
          szolgáltatnunk,  hiszen  azt a DOS a törlésnél eldobta. Ha a
          T1-et  visszahozzuk,  az  Unerase már képes a C:\TEMP\T1-bôl
          kiirtott file-ok megjelenítésére is.

          Nem   bízhatunk   a   Norton   Unerase-ben,  ha  a  törlések
          végrehajtása  óta  már másoltunk a C:\TEMP-be. Ekkor ugyanis
          a  ?1 (volt T1) bejegyzését igénybe vehette a DOS, így annak
          létezésérôl  nem  szerzünk tudomást. Sajnos az Unerase nincs
          felkészítve   erre   a   lehetôségre,   ezért   a   letörölt
          alkönyvtárak   nevét   teljes   biztonsággal  a  CONTROL.FIL
          vizsgálatával állapíthatjuk meg.


           @VAz Undelete és a Mirror@N

          Figyelemre   méltó,   hogy   a   DOS  Mirror  segédprogramja
          alapértelmezésben  nem  fér össze a Delete Sentryvel. (Annál
          is   inkább   meglepô,  mivel  mindkettôt  a  Central  Point
          készítette!)   A  hiba  igen  érdekesen  jelentkezik:  ha  a
          Mirrort  egy  Delete  Sentryvel védett lemezen elindítjuk, a
          következô zajlik le:

          1.  A  Mirror  letörli  a régi indexfile-t, amivel a lemezen
          lévô  mentett  állapotát  elérhette. Ezt a Sentry úgy hajtja
          végre,  hogy  a MIRORSAV.FIL-t átnevezi .MS kiterjesztésûvé,
          és a \SENTRY-be mozgatja.

          2.  A  Mirror  keresést  indít  a  lemez utolsó szektoraiban
          Mirror  index  (maradványok) után. Itt talál egy ????????.MS
          nevû  file-t  a  MIRORSAV.FIL helyén, majd ezt megvizsgálja.
          Mivel  az  adatformátum  jó,  de a név nem egyezik, a Mirror
          hibát jelez:

          @KDrive X error. Data was found in a file that@N
          @K@N
          @Kappears to be a MIRROR control file. Cannot continue.@N

          Természetesen    ilyenkor    a   Mirror   a   visszaállítási
          információkat  sem  menti  el.  A  fentieket  többféleképpen
          küszöbölhetjük ki:

          1.  A  Mirror  és az Undelete AUTOEXEC.BAT-ból való indítása
          esetén elôször a Mirrort, majd az Undelete-t indítsuk el.

          2.  Használjuk  a  Norton  Utilities IMAGE programját, ami a
          Mirror  feladatait  látja el. Az Image-nek nem okoz gondot a
          régi   indexfile   maradványa.   Persze   ezt   csak   akkor
          követhetjük  el,  ha jogtiszta Norton Utilities tulajdonosai
          vagyunk.

          3.  Az Undelete számára írjuk elô, hogy ne törôdjön a Mirror
          részeivel.  Ezt  az UNDELETE.INI [sentry.files szekciójának
          alábbi bôvítése oldja meg:

          @K-MIRROR.FIL -MIRROR.BAK -MIRORSAV.FIL@N


           @VAz Undelete mûködése és a szabad lemezterület@N

          Az  Undelete ügyel arra, hogy a ""törölt" file-okat a DOS ne
          lássa.    A   \SENTRY   könyvtárból   csak   a   CONTROL.FIL
          ""nyilvános",  az  MS  kiterjesztésû file-okat a DOS a lemez
          szabad  területéhez  számítja. îgy a DIR, a Norton Commander
          stb.  több  szabad  területet  jelez, mint amennyi a lemezen
          üres,  értve  ezalatt  a  törölt  file-ok  területén  kívüli
          részeket.  Ez azonban gyanút kelthet, hiszen alacsony szintû
          ellenôrzô   program   (például  a  CHKDSK)  számára  ezek  a
          területek  foglaltnak  számítanak.  Ha  nem  egyezik  a  két
          módszer   által   adott   üresnek  jelzett  méret,  egy  kis
          számítással  ellenôrizhetjük,  vírus vagy az Undelete Sentry
          okozza-e az eltérést.

          Következzen  egy  példa!  (A képernyôn megjelenô szövegekbôl
          csak  a számunkra fontos sorokat hagytuk meg, a kihagyásokat
          (...) jelöli, a sorokat /// jelöléssel választottuk el.)

          A DOS DIR parancs kiírása: (...) 27688960 bytes free

          CHKDSK:  (...)  2048 bytes in each allocation unit /// 13261
          available  allocation  units  on  disk  ///  27158528  bytes
          available on disk

          DIR  \SENTRY\*.MS:  Directory  of  C:\SENTRY  ///  (...)  63
          file(s) 436713 bytes /// 27688960 bytes free

          DIR   \SENTRY\*.FIL   /A:S:   Directory   of  C:\SENTRY  ///
          CONTROL.FIL  7340  08-20-93  9:13a  /// 1 file(s) 7340 bytes
          /// 27688960 bytes free

          A   \SENTRY  lemezen  elfoglalt  helye:  File  Size,  Norton
          Utilities  7.0,  Copyright  1993 by Symantec (...) C:\SENTRY
          (...)  444,053  total  bytes  in  64 files /// 538,624 bytes
           disk space occupied (...)

          A  CONTROL.FIL  lemezen  elfoglalt  helye: File Size, Norton
          Utilities  7.0,  Copyright  1993 by Symantec (...) C:\SENTRY
          ///  CONTROL.FIL /// 7,340 total bytes in 64 files /// 8,192
          bytes disk space occupied (...)

          Az  eltérések  oka:  valóban  szabad:  27158528  byte (13261
          cluster,  veszélytelenül  használható); \SENTRY: 538624 byte
          (263    cluster,    felülírása   információvesztést   okoz);
          CONTROL.FIL:  8192  byte (4 cluster, nem felülírható, lemezt
          foglal);  ????????.MS:  530432  byte (259 cluster, látszólag
          szabad) DOS szabad: 27688960 byte.

          Ha  a  fenti  számítás  végeredménye eltér a DIR által adott
          üres  mérettôl,  valami más garázdálkodik a lemezen (és/vagy
          a memóriában).

          A  látszólag  szabad  területet  a  DOS  lemezreírás  esetén
          igénybe  veszi,  így  a  lemezt teljesen megtöltve az összes
          törölt  file  visszaállíthatatlanná  válik. Ez természetesen
          igaz  a  többi  Undelete formára is, ezeket azonban a Sentry
          felülmúlja,  hiszen  az  általa védett file-ok túlélnek akár
          egy lemezoptimalizálást is.


           @VAz Undelete lemezkezelése@N

          A  Delete  Sentry az általa lefoglalt területet (a \SENTRY-n
          belül)  FIFO-elven kezeli, azaz mindig az utolsónak letörölt
          file-ok  visszaállítására  képes. Ha egy file-t letörlünk, a
          következô megy végbe:

          1.   Ellenôrzés:   befér-e   a   file   a   Sentrynek  adott
          lemezterületre?   Ha   nem,   a  file  törlése  nyom  nélkül
          megtörténik, a Sentry pufferének tartalma nem változik.

          2.  Ellenôrzés:  van-e  annyi  üres  hely,  hogy  a  file  a
          \SENTRY-be  kerülhessen?  Ha  van, megtörténik a ""másolás",
          és a file törlôdik.

          3.  Ha  a  file  nem fér el a Sentry szabad helyén, a Sentry
          addig  töröl  a  tárolt  visszaállítható file-ok közül, amíg
          elegendô   terület   nem   szabadul   fel.  Ekkor  a  törlés
          megtörténik.  A  visszaállítható  file-ok  eldobása  törlési
          idôpont (dátum) szerinti sorrendben történik.


           @VÅltalános tanácsok@N

          Az  Undelete-et  célszerû  az  AUTOEXEC.BAT-ból  telepíteni.
          Ezzel  elkerülhetjük,  hogy  a  helyi szokásokat nem ismerve
          valaki  felügyeletlen  törlési  mûveletekkel  tudtunk nélkül
          kárt  okozzon.  Elôfordulhat, hogy az Undelete nagyon lassan
          ""áll  talpra".  Ez azt jelenti, hogy nagyon sok törölt file
          ""szavatossági     ideje"    lejárt,    azaz    letelt    az
          UNDELETE.INI-ben megadott megôrzési határidô.

          Különösen   fejlesztôi   környezetben  (ahol  szükség  lehet
          gyakori       rendszerújraindításra)       ajánlatos      az
          AUTOEXEC.BAT-ból  kiszûrni  az  olyan  programokat,  amelyek
          átmeneti  file-okat  hoznak  létre,  majd  azokat törlik. Ez
          ugyanis   azt  jelenti,  hogy  minden  rendszerindulás  után
          lassanként  töltôdik a Sentry puffere. îgy egy idô után csak
          az   átmeneti   file-okat   találjuk   majd  visszaállítható
          állapotban.   E   veszély   fôleg   a   nagyra   duzzasztott
          AUTOEXEC.BAT-ok    tulajdonosait   fenyegeti.   (Pl.   @K|MORE@N
          vagy   @K|SORT@N   az   AUTOEXEC.BAT-on  belül.)  Érdemes  ezért
          néhány  reset után megszemlélni, helyezett-e a Sentry törölt
          file-t a \SENTRY-be. Ha igen, kezdôdhet az ok felderítése.

          Ha  rendszerindítás  során rendelkezünk memórialemezzel (RAM
          drive),  célszerû a TEMP környezeti változót ide irányítani,
          és  magát  a  memórialemezt  a Sentry számára nem védendônek
          nyilvánítani.  Ilyenkor  a  DOS  átmeneti file-jait a Sentry
          nem követi.

          Ha  nincs  memórialemezünk,  érdemes  a kiterjesztés nélküli
          file-ok  figyelmen  kívül hagyását elôírni a Sentry számára,
          ilyenek  ugyanis a DOS átmeneti file-jai. Ez az UNDELETE.INI
          [sentry.files@N szakaszának alábbi bôvítését jelenti:

          @K-*.@N

          Nagy  mennyiségû,  biztosan  felesleges  adat törlése esetén
          (például  egy  több  (tíz)  Mbyte-os  program verziócseréje)
          célszerû  a  Delete Sentry kikapcsolása mellett végrehajtani
          a  mûveletet.  Ilyenkor  ugyanis  a  törlés során nem válnak
          visszállíthatatlanná   olyan   adatok,  amelyek  elvesztését
          késôbb   megbánnánk   (például  egy  fejlesztés  alatt  álló
          program  tegnapelôtti állapota, amelynek végleges elvesztése
          nagyobb  gondot  jelenhet,  mint  a teljes CorelDraw 3.0). A
          kikapcsolásra   az   UNDELETE   /UNLOAD  szolgál.  Ekkor  az
          UNDELETE  nem  láncolja ki magát, ha valaki más használja az
          általa  figyelt  megszakításokat  (16H,  19H, 21H, 25H, 26H,
          2FH).  Ez  nem gond, ha az utolsó betöltött rezidens program
          az   Undelete.   Az   MS  DOS  6.0  MEMMAKER-je  azonban  az
          Undelete-et  többnyire  a  felsô memóriába elsônek betöltött
          TSR-k  közé  teszi,  mivel  töltési  mérete  (mintegy  28 K)
          lényegesen  meghaladja  a végleges rezidens méretet (mintegy
          13 K).

          Ha  egy  könyvtár  megsemmisítése  kedvéért nem szeretnénk a
          rendszert   újraindítani,   és   az  Undelete  nem  hajlandó
          kiláncolódni, az alábbi módszerek közül választhatunk:

          1.  Alkalmazzuk  a  technikai  részletek között ismertetett,
          SUBST   parancsra   alapozott   eljárást.  Helyettesítsük  a
          törlendô  könyvtár  nevét  egy  meghajtóra,  majd  töröljünk
          onnan mindent:

          @KSUBST D: C:\TEMP@N
          @KD:@N
          @KCD \@N
          @KECHO Y | DEL *.*@N
          @K(esetleges alkönyvtárak törlése:)@N
          @KCD T1@N
          @KECHO Y | DEL *.*@N
          @K(...)@N
          @KSUBST D: /D@N

          2.  Keressünk  olyan file-specifikációt az UNDELETE.INI-ben,
          amit   a   Sentry   nem   véd.  Ezek  a  [sentry.files  sor
          mínuszjellel  kezdôdô  tagjai.  Ha  minden  kiirtandó file-t
          ilyen  névre  nevezünk át, azokat gond nélkül letörölhetjük.
          (A  TMP  kiterjesztésû  file-ok  többnyire védtelenek.) Ez a
          módszer  kényelmetlen,  ha  nagyon  sok  alkönyvtárunk  van.
          Ilyen  esetben  a könyvtárfákat kezelô programok segíthetnek
          (Norton Commander 4.0, TARGET stb.).

          3.  A  felesleges  könyvtárstruktúrát átmozgathatjuk egy nem
          védett meghajtóra, majd innen törölhetjük.

          @KVisegrády Tamás@N